All config values supported by loaders config API are inherently ordered. Since the behavior of an unordered collection is undefined and I struggle to think of when any of the possible behaviors might be useful, I don't think it really needs to be included.

I think supporting custom widget types is important. If somebody wants to implement a color wheel widget for their config option, they should be able to do so. Even if their widget doesn't appear alongside other widgets, a solution that opens another screen to edit the option would seem reasonable to me. I think restricting widgets to a small set of types will lead to some less-than-optimal end user experiences.

I don't love the term "category" here. I would ordinarily assume that each setting belongs to only one category, similar to how game rules have a single category or biomes have a single category. I'm not sure what a better word would be, but wanted to open the discussion.

I think it's important that no matter what our system ends up being, we provide reasonable default behaviors for any type. This seems like it would be a good place to note that.

I don't think this is necessary at all. We should have one standard way of displaying collections, and collections should simply define the widget type used by all of their children.

I also don't think this is necessary. WIDGET_TYPE should just be a MetadataType<Function<TrackedValue<?>, Widget>>, with different kinds of widgets having either constructors or helper methods for different parameter types. ToggleWidget for instance could have the following method:

public static Widget create(TrackedValue<?> value) {
  Object defaultValue = value.value();

  if (defaultValue instanceof Boolean) {
    return new ToggleWidget(value.value());
  } else if (defaultValue instanceof Enum e && e.values().length == 2) {
    return new EnumToggleWidget(value.value());
  } else if (...) {
  
  } else {
    throw new WidgetCreationException(...); // Might be better to have some sort of result class instead of throwing errors, but ¯\_(ツ)_/¯ 
  }
}

The value would then simply call

builder.metadata(WIDGET_TYPE, builder -> builder.factory(ToggleWidget::create))

CLIENT_ONLY and SERVER_ONLY are functionally identical. I would therefore rename this class to SyncPolicy or something along those lines and condense those two options to NONE, with SERVER_SYNCED becoming S2C and CLIENT_SYNCED becoming C2S. Additionally, I might add a P2P sync type that shares user configs with other clients in a way that allows them to be accessed on a per-player basis. This has a lot of valuable implications for user-set display information (nicknames come to mind).